1. Technical Field
The present invention relates generally to data storage. More particularly, the present invention relates to a system and method for providing highly-available volume mount points.
2. Description of Related Art
Companies today rely to an unprecedented extent on online, frequently accessed, constantly changing data to run their businesses. Unplanned events that inhibit the availability of data and applications can seriously damage business operations. Therefore, when disaster strikes, companies must be prepared to eliminate or minimize data loss, and recover quickly using alternate resources.
Clustering is a strategy wherein data processing systems and storage devices are interconnected, typically at high speeds within a site, for the purpose of improving reliability, availability, serviceability, and/or performance via load balancing and/or transition in the event of a failover or switchover condition. Such transitions may take place as a result of administrator intervention (e.g., for maintenance or load distribution) or automatic selection for load distribution and balancing (switchover), and/or due to a failure of an active or primary node (failover). Redundant interconnections between the data processing systems or “nodes” are typically included as well, and the collection of data processing systems, storage devices, and redundant interconnections is referred to herein as a server cluster. The server cluster appears to users as a single highly-available system.
Nodes within a cluster often use a common pool of storage devices, with the purpose of the cluster being to provide alternative processing resource(s) for the data on the shared storage resources (e.g., disks, plexes, volumes, etc.) following a transition between nodes. Only one of the nodes in the cluster generally provides processing resources with respect to a particular software application at a time. The system currently providing processing resources in the cluster for a particular software application is referred to herein as a primary node, and other systems in the cluster are referred to herein as secondary nodes. The terms “primary node” and “secondary node” are used in the context of a particular software application, such that a primary node for one application may serve as a secondary node for another application, and a secondary node for a third application may serve as a primary node for yet another application.
Each server cluster typically runs a software application to coordinate the activities of the nodes within the cluster. This software is referred to herein as a cluster manager, cluster management application, or “cluster server”. A cluster server may monitor the health of sites in a distributed server cluster system and restart an application on another node when the node running the application fails. Typically, cluster management functions are limited to such clustering operations as monitoring, starting, and stopping resources.
Using prior versions of Microsoft's Windows® operating system (e.g., Windows® 3.x, Windows® 95, Windows® 98, etc.) volumes within shared storage were accessed using drive letters (a-z). Because of drive letters required for the floppy drive, a system/boot volume, and a CDROM, nodes were limited to being able to access only up to 23 volumes. This limitation was removed from Windows® 2000 onwards by adding support for volume mount points. A volume mount point is directory or folder within the Windows® namespace (e.g., a directory or “folder”) of a volume which represents another volume in a persistent, robust manner, thus eliminating the need to assign a drive letter to each volume and allowing system administrators to transcend the previous 23 volume/drive limitation. Using volume mount points causes a node's storage subsystem to transparently resolve accesses of volume mount point directories or folders within a “base” volume to the root of a specified “target” volume.
Volume mount points allow storage to be made scalable and easily manageable and accordingly support for such volume mount points within a highly-available/server cluster environment is desirable. Several characteristics of volume mount points make them particularly difficult to implement in a cluster environment. For example, a target volume may become inaccessible due to the inaccessibility of its base volume, or because the target's base volume isn't accessible using the same access path across nodes of a server cluster or the same node following a system shutdown, restart, or administrative change. Accordingly, conventional server cluster systems do not provide support for volume mount points within shared storage resources such as those of cluster server environments.